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Beschreibung 



Verfahren und Vorrichtung zum Bezahlen in Netzen bei einmali- 
ger Anme Idling 

Fachgebiet der Erfindung 

Um in einem Netz, sei es ein Mobilfunk- oder auch das Inter- 
net - tatig sein zu konnen, ist es er f orderlich, dass ein 
Nutzer eine Net z-Identitat (auch Account) erhalt. Dieses 
Netz-ID umfasst Angaben liber Nutzer-Kennung, Passwort, Adres- 
sen, Kredit-Karten Nummern, und gegebenenf alls auch Nutzer- 
Profile, wie „Bookmarks\ Einstellungen, Praferenzen, 
etc. .Bislang ist es ublich, dass sich ein Nutzer eines Kommu- 
nikationsnetzes fur jede Anwendung, die er nutzen will, sepa- 
rat anmelden muss, da diese Anwendungen in der Regel getrennt 
voneinander ablaufen. Dieses ist vor allem erf orderlich, wenn 
diese Anwendung eine Authentif izierung oder Autorisierung 
verlangt. Mit wachsender Zahl von Anwendungen, die ein Nutzer 
verwenden will, steigt so auch die Anzahl solcher Nutzer-Pro- 
file, die er zu verwalten hat. Es ergeben sich also offen- 
sichtlich Nachteile, denn der Nutzer muss sich jedes Profil 
merken, gegebenenf alls Nut zer kennung und Passwort und gegebe- 
nenf alls weitere Inf ormationen die er in dem jeweiligen Pro- 
fil angegeben hat, oder auch nicht angegeben hat. 



Stand der Technik 



Inzwischen gibt es fur dieses Problem verschiedene Losungen: 
beispielsweise der ^Passport" Dienst der Firma Microsoft oder 
das „Liberty Alliance Project^ (LAP) 

(www.projectliberty.org), das im September 2001 ins Leben ge- 
rufen wurde . 



In den Spezif ikationen des Liberty Alliance Projekts werden 
verschiedene Verfahren der Authenti f i zierung und Autorisie- 
rung (A&A) beschrieben, mit dem Ziel, einen Einmal-Anmelde- 
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vorgang, ein sogenanntes „Single Sign-On* (SSO) Verfahren, 
fur den Endnutzer anzubieten. 

• Eine herstellerunabhangige Einfiihrung liber „Single Sign-On* 
findet man z. B. auch unter: 

www.opengroup.org/security/sso/sso_intro.htm. 

Urspriinglich wurde dieser Ansatz hauptsachlich fur IT-Systeme 
entwickelt, in denen das Nutzen der meisten Dienste an sich 
bislang in der Regel kostenfrei ist. Dazu siehe auch die Bei- 
spiele des Liberty Alliance Project, welche die Reservierun- 
gen bei einer Fluglinie und einem Fahr zeugverleih iiber Netz 
beschreibt, der Reservierungsvorgang an sich ist kostenfrei. 
Vorteilhaft bei diesem Verfahren ist ausserdem, dass kreuz- 
weise Daten zwischen den einzelnen Diensten (Bonus-Meilen) 
ausgetauscht werden konnen. Solche Verfahren umfassen bislang 
keine Losung fur das Bezahlen von Diensten und/oder Inhalten, 
der Zahlungsvorgang wird nach dem Sign-On Vorgang separat ab- 
gewickelt, beispielsweise iiber die angegebene Kredit Karte. 

In ^Charging, Billing and Payment views on 3G Business Mo- 
dels", UMTS Forum Report No. 21, 2002 (www.umts-forum.org/ 
reports.html) vom 21.07.2002 wurde diese Liicke bereits ange- 
sprochen, doch es wurde dort keine Losung dieses Problems 
vorgestellt . 

In Mobilfunknetzen existieren weiterhin einige eingeschrankte 
Losungen fur die Bezahlung von externen Diensten und Inhalten 
im Zusammenhang von PrePaid Services: 

Eine Abwicklung ist mbglich iiber einen Guthaben („Wallet*) 
Server beim Mobilf unk-Net zbetreiber , iiber den zuvor eine ex- 
plizite Authentif izierung und Autorisierung des Benutzers 
durchgefuhrt wird. Diese Losung ist allerdings teuer und nur 
fur groBere Transakt ionswerte geeignet. 

Die Abrechnung des Inhaltes kann indirekt uber die Transport- 
Gebiihren (z. B. uber eine bekannte ,,0190* -Nummer ) erfolgen. 
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Diese Losung ist fur den Nutzer wenig transparent (d. h. die 
verrechneten Gebuhren fur den Inhalt sind von denen fur die 
Verbindung nicht trennbar und damit nicht nachvollziehbar ) . 
Diese Losung wurde in der letzten Zeit von unseriosen Anbie- 
ter miflbraucht und ist daher inzwischen in Verruf geraten. 

Der externe Anbieter kann die Preisinf ormationen bei der Aus- 
lieferung des Dienstes in den Datenstrom einftigen. Diese wird 
dann vom Mobilf unk-Net zbetreiber aufgefangen und ausgewertet. 
Das Kostenrisiko liegt hier aber beim Anbieter, da bei man- 
gelnder Zahlungsdeckung des Nutzers der Dienst bereits er- 
bracht war. 

Aufgabe der Erfindung ist es, ein verbessertes Verfahren zur 
Bezahlung von Inhalten und Diensten anzugeben, sowie eine 
Vorrichtung zur Durchfuhrung des Verfahrens. 

Darstellung der Erfindung 

Diese Aufgabe wird gelost indeni ein Mobilf unk-Net zbetreiber 
(MNO) als sogenannter Identity-Provider (A&A) ( insbesondere 
gemafi der Liberty Alliance Architektur (siehe Figur lb)) fur 
seinen Endkunden gegenliber externen Anbietern (3rd Party ASP) 
von mobilen Diensten und Inhalten agiert und auch den Bezahl- 
vorgang dieser Inhalte und Dienste ubernimmt . Damit ist der 
Mobilfunk-Netzbetreiber in der Lage, diese Funktionen zu in- 
tegrieren. 

Wahrend der bei dem Einmal-Anmeldevorgang (Single Sign On) 
stattf indenden Authentif izierung und ggf . Autorisierung fin- 
det bereits eine Guthaben- bzw. Kreditpruf ung statt. Das Er- 
gebnis wird dem externen Anbieter mitgeteilt, so dass gegebe- 
nenfalls eine Autorisierung mangels ausreichender Deckung fur 
die Nutzung eines Dienstes bereit im Vorfeld versagt werden 
kann. Dies ist z. B. der Fall, wenn das vorhandene Guthaben 
des Nutzers geringer ist als die Mindest-Nut zungsgebtihr des 
Dienstes . 
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Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den 
Unteranspruchen angegeben. 

Bisherige Zahlungsver f ahren sehen eine Reservierung bzw. Zah- 
lung des Dienstes erst nach Auswahl und Nutzung vor. 
Bei dem erfindungsgemaJJen Vorgehen kann eine verbindliche Re- 
servierung des Betrages bereits vor der Nutzung geschehen: 
das hier beschriebene Verfahren verknupft die Authentif izie- 
rung des Benutzers mit der Autorisierung und Reservierung des 
Betrages, bevor der Dienst in Anspruch genommen wird. Der ex- 
terne Dienstanbieter muss die Auslieferung des Dienstes, fur 
die der Betrag reserviert wurde, an den Mobilf unk-Net zbetrei- 
ber innerhalb eines zu bestimmenden Zeitraumes bestatigen. 
Wahlweise kann der Betrag auch nicht reserviert, sondern dem 
externen Dienstanbieter nur ein unverbindlicher Hinweis uber 
die vorhandene Deckung der Summe gegeben werden. 

Durch die Erfindung wird die Vermarktung von Datendiensten im 
Umfeld immer weiterer verschiedener Anbieter vereinfacht. 

Die im Dialog durchgef uhrte Online-Autorisierung (auch „Ad- 
vice-of-Charge\ AoC genannt) und die Online-Reservierung 
wird mit der Online-Authentif izierung verknupft und dem Mo- 
bilf unk-Netzbetreiber uberlassen. Der externe Dienstanbieter 
ist somit urn diese Funktion entlastet und muss nur die er- 
folgreiche Auslieferung des Dienstes bestatigen. 

Die Online-Autorisierung wird vom Mobilf unk-Netzbetreiber 
(als vertrauenswurdigem Dritter, auch ^trusted party* ge- 
nannt) erbracht und nicht vom Diensterbringer. Dieses Ver- 
trauensverhaltnis kann ausschlaggebend sein fur den Erfolg 
des Dienstes, da der Nutzer direkt immer nur mit dem eigenen 
Mobilfung-Netzbetreiber zu tun hat. 

Die in der Beschreibung vorgenommene Trennung zwischen Mobil- 
funk-Net zbetreiber und Diensterbringer muss aber nicht bedeu- 
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ten, dass dieses raumlich getrennte Einheiten sind. Die Un- 
terscheidung dient lediglich der besseren Verstandlichkeit 
und erfolgt in Anlehnung an die Terrninologie des Liberty Al- 
liance Projektes. Andere Anordnungen sind dem Fachmann gelau- 
f ig . 

Kurzbeschreibung der Zeichungen 

Figur la ist eine Darstellung der vom Verfahren betroffenen 
Netzelemente, 

Figur lb ist eine Ubersicht uber die Liberty Architektur, 
Figur 2 zeigt ein Datenf luss-Diagramm. 

Figur la zeigt eine Architektur auf der die Durchfiihrung des 
erfindungsgemafien Verfahrens moglich ist. Die Kommunikation 
zwischen einem Nutzer (Terminal), dem Mobilf unk-Net zbetreiber 
(MNO) , der einen Authentif izierungs-Server (AAA Server) , ei- 
nen Gateway / Web Proxy (GW) , und einen Zahlungsserver (Pay- 
ment Server) beinhaltet, und einem Diensterbringer (3rd Party 
Appl. Server) auf der anderen Seite. 

Figur lb zeigt die bekannte Architektur des Liberty Alliance 
Projektes, wie sie derzeit in cien offiziellen Spezif ikationen 
dargelegt ist. 

Der Nutzer (user) steht dabei zwei weiteren Net zelementen ge- 
genuber: Der Service Provider bietet die vom Nutzer angefor- 
derten Dienste (Web Services) an. Die Authentif izierung des 
Nutzers erfolgt zuvor als Single Sign-On bei einem Identity 
Provider . 

Das ausgefuhrte Datenf luss-Diagramm der Figur 2 zeigt bei- 
spielhaft, wie die hier beschriebene Verfahren durchgeflihrt 
werden kann. 

Dabei konnen folgende Schritte durchlaufen werden: 
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A. Der Nutzer forder einen Dienst vom Diensterbringer liber 
das Mobilfunknetz des Net zbetreibers an (re- 
quest_service ( ) , 0 . ) . 



B. Der Diensterbringer richtet eine Authentisierungs-Anf rage 
(request_authn ( service_amount ) , 1.) an den Mobilfunk- 

Netzbetreiber, der fur den Nutzer agiert. 

C. Die Authentisierungsnachf rage (re- 

quest_authn (service_amount) , 2.) wird dann mit Hilfe einer 
Redirect Anfrage liber das Terminal des Nutzers zum Mobil- 
funk-Netzbetreiber gesendet, wie hier dargestellt. 

C*. Alternativ kann die Authentisierungsnachf rage (re- 

quest_authn (service_amount) ) entsprechend der LAP Spezifi- 
kation direkt an den Mobilf unk-Net zbetreiber geschickt 
werden . 



D. Die Authentisierungsanf rage enthalt die Preisinf ormation 
zum nachgefragten Dienst (service_amount ) . Diese Informa- 
tion wird vom Mobilf unk-Net zbetreiber genutzt, urn den ent- 
sprechenden Betrag vom Konto des Nutzers zu reservieren 
(reserve_amount ( service_amount ) , 6.). 

E. Nach der er f olgreichen Reservierung (con- 

f irm_reservation ( ) , 7.) sendet der Mobilf unk-Netzbetreiber 
die notwendigen nutzer- und dienstspezif ischen Authenti- 
sierungs- und Autorisierungsinf ormationen (return token 
(AACtoken) , 9., response_authn (AACtoken) , 10.) zusammen 
mit der Information liber die erfolgte Reservierung an den 
Diensterbringer (ASP), response_authn (AACtoken), 11.). 

F. Der Diensterbringer stellt daraufhin den Dienst fur den 
Nutzer bereit (deliver_service ( ) , 12.) und informiert den 
Mobilfunk-Netzbetreiber liber die erfolgte Lieferung (con- 
f irm_service_delivery ( ) , 13 . , 14 . ) . 
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G. Der Mobilfunk-Netzbetreiber bucht nach Erhalt der Liefer- 
bestatigung den vorab reservierten Betrag vom Konto des 
Nutzers ab (charge_amount ( ) , 15.). 

Die Reservierung erfolgt also zusammen mit der Authentisie- 
rung und Autorisierung des Nutzers und vor der Bereitstellung 
des Dienstes durch den Diensterbringer . Optional kann der Mo- 
bilfunk-Netzbetreiber vor der Reservierung des Betrages noch 
eine Autorisierung (AoC) durch den Nutzer ermoglichen. (aoc 
(service_amount, 3., conf irm_amount ( ) , 4.) 
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Patentanspruche 

1. Verfahren zur Vergebuhrung von Diensten oder Inhalten in 
einem Kommunikationsnetz (MNO) 

a) bei dem der Nutzer (Terminal) sich zuvor im Netz (AAA) 
einmalig angemeldet hat und 

b) der Nutzer (Terminal) dann bei einem Diensteanbieter (ASP) 
einen Dienst oder einen Inhalt anfordert (request_service ( ) ) , 
und 

c) im Netz (AAA) nach Aufforderung des Diens tanbieters (re- 
quest_authn (service_amount) ) uberpruft wird, ob eine ord- 
nungsgemafte Vergebuhrung des Nutzers fur den Dienstanbieter 
(ASP) moglich ist (reserve^amount (service_amount) ) , und 

d) nach Uberpriifung die Ausflihrung des Dienstes freigegeben 
wird (response_authn (AACtoken) ) . 

2. Verfahren nach Patentanspruch 1, 
dadurch gekennzeichnet , dass 

c y ) eine verbindliche Reservierung des Betrages (servi- 
ce_amount) fur den externen Dienstanbieter (ASP) stattfindet 
(conf irm_reservation ( ) ) . 

3. Verfahren nach Patentanspruch 1, 
dadurch gekennzeichnet, dass 

c x ) ein unverbindliche Hinweis uber eine erfolgreiche Uber- 
priifung der Vergebuhrung an den externen Diens terbringer er- 
folgt. 

4. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet, dass 

der externe Diensterbringer die Auslieferung des Dienstes o- 
der Inhaltes bestatigen muss (conf irm_service delivery ()). 

5. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

die Bestatigung der Auslieferung des Dienstes innerhalb eines 
vorbestimmten Zeitraumes eingehen muss. 
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6. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet , dass 

der Nutzer den fur den Dienst reservierten Betrag (servi- 
ce_amount) autorisieren kann (conf irm_amount () ) . 

7. Vorrichtung in einem Kommunikat ionsnetz (MNO) zur Durch- 
fuhrung des Verfahrens gemaU Patentanspruch 1, mit 

- Mitteln zur Authentif izierung und Autorisierung (AAA) , 

- Mitteln zur Durchfuhrung der Bezahlung (Pay) , und 

- Mitteln zur Kommunikat ion mit dem Nutzer (Terminal) und 
externen Diensteanbietern (3 rd Party ASP), 

dem der Nutzer (Terminal) sich zuvor im Netz (AAA) einmalig 
angemeldet hat und 

von dem Nutzer (Terminal) dann uber die Mittel zur Kommunika- 
tion bei einem Diensteanbieter (ASP) ein Dienst oder einen 
Inhalt anforderbar ist und 

durch die Mittel zur Authentif izierung und Autorisierung 
(AAA) nach Aufforderung des Dienstanbieters (re- 
quest_authn (service_amount) ) uberpruft wird, ob eine ord- 
nungsgemalie Vergebuhrung des Nutzers fur den Dienstanbieter 
(ASP) moglich ist. 
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Zusammen fas sung 

Verfahren und Vorrichtung zum Bezahlen in Netzen bei einmali- 
ger Anmeldung 



Ein Mobilfunk-Netzbetreiber (MNO) agiert als sogenannter I- 
dentity-Provider (A&A) fur seinen Endkunden gegeniiber exter- 
nen Anbietern (3rd Party ASP) von mobilen Diensten und Inhal- 
ten. Er kann so auch den Bezahl vorgang dieser Inhalte und 
Dienste ubernehmen. Wahrend der bei dem Einmal-Anmeldevorgang 
(Single Sign On) statt f indenden Authentif izierung und ggf . 
Autorisierung findet bereits eine Guthaben- bzw. Kreditprii- 
fung statt. Damit ist der Mobilfunk-Netzbetreiber in der La- 
ge, diese Funktionen zu integrieren. 



Figur la 
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